home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14217 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.6 KB
  1. Path: news.tiac.net!usenet
  2. From: jkinsella@procd.com (Joe Kinsella)
  3. Newsgroups: comp.lang.smalltalk,comp.object,comp.lang.c++,comp.lang.java
  4. Subject: Re: The Good, the Bad, the Ugly, and the Wicked ...
  5. Date: Fri, 29 Mar 1996 14:24:00 GMT
  6. Organization: The Internet Access Company
  7. Message-ID: <4jgrr6$838@news.tiac.net>
  8. References: <31570B8E.5A12@vmark.com>
  9. NNTP-Posting-Host: doug.procd.com
  10. X-Newsreader: Forte Free Agent 1.0.82
  11.  
  12. Jeff Sutherland <jsutherland@vmark.com> wrote:
  13.  
  14. >                    ST    C++    OOC     Java
  15. >Flexibility    Dynamic Binding        1    2    2    2
  16. >        Dynamic Classes        1    3    1    2
  17. >        Multiple Inheritance    3    2    2    3
  18. >        Roles            2    3    3    1
  19.  
  20. Dynamic Binding & Classes - I am not sure why "better" dynamic binding
  21. and classes somehow gives a language better flexibility.  I can see
  22. some incremental advantages in development time, but I would consider
  23. dynamic binding a negative quality in a product system.
  24.  
  25. >Ease of use    Class Libraries        1    3    3    2
  26. >        Learning Curve        1    3    2    1
  27. >        Speed of Development    1    3    2    2
  28. >        Portability        2    3    3    1
  29.  
  30. Class Libraries - I guess you can't get more deceptive than this.
  31. What are we talking about here?  Smalltalk has a de-facto standard
  32. that defines a broad set of base classes (streams, collections).  But
  33. I've never worked on a C++ project that did not have an equivalent
  34. class library.  In fact, the number and variety of class libraries
  35. available to me as a C++ programmer far exceeds that available to
  36. Smalltalk programmers.  Aren't you just rating what class libraries
  37. are typically provided in the box?  If so, isn't that a packaging
  38. issue and not a language issue?
  39.  
  40. Learning Curve - I found the learning curve for Smalltalk to be
  41. *extremely* steep (yeah, simple syntax but it takes a while to get the
  42. nuances of the language).  Most of the Smalltalk consultants I know
  43. agree the learning curve for Smalltalk is an impediment to the
  44. language.
  45.  
  46. Speed of Development - I've delivered commercial products with both
  47. Smalltalk and C++, and I just can't agree with you here.
  48.  
  49. Portability - Ouch!  You are once again confusing packaging with a
  50. language.  This is turning out to be a marketing check list--not a
  51. language assessment!  As a VC++ developer, I can cross compile my MFC
  52. applications to the Macintosh.  When IBM completes support for MFC on
  53. OS/2, I will also be able to cross compile to OS/2.  And if I didn't
  54. want to use VC++ or MFC, I still have a variety of libraries that
  55. would give me this portability.  Smalltalk is portable only within a
  56. single vendor's product (e.g. an ST-80 app will not run on VA since
  57. every vendor has different class libraries for things like GUI,
  58. database connectivity, etc...).
  59.  
  60. >Support        Tools        1    1    3    3
  61. >        Multiple Vendors        2    1    3    1
  62.  
  63. Tools - What are tools?  Are we talking about available 3rd party
  64. products?  If so, Smalltalk should rate a 3+ here since it has an
  65. extremely small 3rd party market.  C++ has an enormous 3rd party
  66. market.  Why does ST rate so high here?
  67.  
  68. >Performance                2    1    3    3
  69. >Risk        Garbage Collection    1    3    3    2
  70. >        Memory Leaks        1    3    1    1
  71. >        Overwriting Memory    1    3    1    1
  72. >        Ready for Prime Time    1    1    2    3
  73.  
  74. Garbage Collection - I didn't know garbage collection was always a
  75. positive trait!  A C++ programmer has access to garbage collectors.
  76. Fortunately it is not a requirement.
  77.  
  78. Memory Leaks & Overwriting Memory - Since most Smalltalk VMs and
  79. connectivity components are written in C, don't they also share a risk
  80. of leaking/overwriting memory.  Unfortunately for the ST developer,
  81. this risk is out of their control.
  82.  
  83. >TOTAL        (low means best)    21    35    34    28
  84.  
  85. I think it is obvious you work for a Smalltalk vendor.  What is not
  86. obvious is why Object Magazine would publish such a blatent piece of
  87. marketing as an objective analysis!
  88.  
  89. Joe
  90.  
  91.  
  92.  
  93.